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SYSTEM AND METHOD FOR PROVIDING ACCESS TO VERIFIED 
PERSONAL BACKGROUND DATA 



Cross-Reference to Related Applications 

This application is a continuation of application serial number 
09/472,080, filed December 23, 1999, which claims the benefit of provisional 
application serial number 60/168,094, filed November 30, 1999; these related 
applications are hereby incorporated herein by reference. 

Technical Field 

The present invention relates to systems and methods for 
authenticating and registering personal background data, including over 
networks and particularly the Internet. 



Background Art 

Misrepresentations by job applicants of their backgrounds put 
employers at risk of hiring persons lacking in training or experience that 
employers were counting on when the applicants were hired. Indirectly such 

20 misrepresentations, besides camouflaging the absence of training or 
experience, also are indicative of potentially unreliable employees. 
Employers also risk public embarrassment when an employee's 
misrepresentations are discovered, regardless of the employee's job 
performance. There have therefore arisen over time a variety of services 

25 providing background checking of applicants for employment. 

Summary of the Invention 

In accordance with one aspect of the invention, access to verified 
personal background data is provided in the form of an electronic document 
30 that includes a data record having personal background data and 

corresponding verification information as well as an electronic authentication 
of the contents of the data record. The data record is associated with a unique 
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identifier. The electronic document may be distributed over a communication 
network to a person providing the identifier. 

In one embodiment there is provided a method of providing access to a 
candidate's verified personal background data. A data record relating to the 
5 candidate's personal background data is established in a digital storage 

medium. The data record is associated with a imique identifier and includes 
a set of potentially verifiable components based on information supplied by 
the candidate and a corresponding set of query results, the corresponding set 
including, with respect to each component, the result of a verification query to 

10 a third party. The identifier is conmiunicated to the candidate, who may 
directly or indirectly provide the identifier to others. Upon receipt of the 
identifier from an outside user over a communication network, an electronic 
document including the data record and an electroruc authentication of the 
contents of the data record is distributed to the outside user over the 

15 communication network. The electronic authentication is capable of revealing 
unauthorized modifications of the contents of the data record. 

The electronic document may be distributed in the form of an 
electronic mail message or electronic file. The electroruc document may be 
distributed over the Internet or other commimication network. The electronic 

20 authentication may be an electroruc watermark or electronic certification. The 
set of components may include the candidate's resume information, in which 
case the set of query results may include information verifying the 
candidate's resume information. 

In another embodiment there is provided a system for providing access 

25 to a candidate's verified personal backgrotmd data. The system includes a 
storage arrangement on which is stored a database having a plurality of data 
records. Each data record relates to personal backgroimd data of a candidate. 
Each data record is associated with a unique identifier that is communicated 
to the candidate and includes a set of potentially verifiable components based 

30 on information supplied by a candidate and a corresponding set of query 

results, the corresponding set including, with respect to each component, the 
result of a verification query to a third party. The system also includes a 
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process, running on a computer in communication with the digital storage 
medium, for selectively distributing, to an authorized person presenting an 
identifier received directly or indirectly from a candidate, over a 
communication network, an electroruc document including the candidate's 
5 data record and an electronic authentication of the contents of the data record, 
the electronic authentication capable of revealing unauthorized modifications 
of the contents of the data record. 

In yet another embodiment there is provided a computer-readable 
medium having embodied therein an electronic document including a data 

10 record and an electronic authentication of the contents of the data record. The 
data record includes a set of potentially verifiable components based on 
information supplied by a candidate and a corresponding set of query results, 
the corresponding set including, with respect to each component, the result of 
a verification query to a third party. The electronic authentication is capable 

15 of revealing unauthorized modifications of the contents of the data record. 

The electronic authentication may be an electronic watermark or 
electronic certification. The set of components may include the candidate's 
resume information, in which case the set of query results may include 
information verifying the candidate's resume information. 

20 

Brief Description of the Drawing s 

The foregoing features of the invention will be more readily 
understood by reference to the following detailed description, taken with 
reference to the accompanying drawings, in which: 
25 Fig. 1 is a block diagram of an embodiment of a method in accordance 

with the present invention for authenticating a candidate's personal 
backgroxmd data. 

Fig. 2 is a block diagram illustrating generally a process flow associated 
with a further embodiment in accordance with the present invention. 
30 Fig. 3 is a diagram illustrating a system in accordance with the 

embodiment of the present invention for carrying out processes accordingly. 



-3- 



15256-116-297428 
02/25/04 



Figs. 4A and 4B illustrate in further detail logical flow of the registrant 
data-entry process of an embodiment similar to that of Fig. 2. 

Figs. 5A and 5B illustrate in further detail logical flow of the 
verification process of an embodiment sinnilar to that of Fig. 2. 
5 Figs. 6A and 6B illustrate in further detail logical flow of the registrant- 

request process of an embodiment similar to that of Fig. 2. 

Figs. 7 A through 7C illustrate in further detail logical flow of the 
process for outside requests on a registrant of an embodiment similar to that 
of Fig. 2. 

10 Figs. 8A and 8B illustrate in further detail logical flow of the process for 

outside requests on a non-registrant of an embodiment similar to that of Fig. 
2. 

Figs. 9A and 9B illustrate in further detail logical flow of the process for 
finding a registrant of an embodiment similar to that of Fig, 2. 

15 

Detailed Description of Specific Embodiments 

Fig. 1 is a block diagram of an embodiment of a method in accordance 
with the present invention for authenticating a candidate's personal 
background data. In box 11, there is established and stored a data record 14 

20 that pertains to the personal backgroimd data. The data record has a unique 
identifier 143. The data record also includes a set 141 of components of the 
candidate's personal background data. 

Each component of the set 141 is potentially verifiable. Examples of 
verifiable components of personal background data include present and 

25 previous employers of the candidate, dates of employment by each such 

employer, positions held at each employer and the dates such positions were 
held, names of persons who have agreed to serve as references for the 
candidate, and the dates they agreed to do so, the text of the references or 
recommendations, educational institutions from which the candidate was 

30 graduated, the degrees granted to such candidate, the dates on which such 
degrees were granted, branches of the armed forces in which the candidate 
served, periods of service in such branches, ranks held during such periods. 
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type of discharge, military medals or honors, and so forth. What these 
components have in common is that they are objective; the components 
involve factual matters that are either correct or incorrect. Because the 
components are not affected by individual judgment, they are susceptible to 
5 verification by inquiry to the pertinent party, such as the employer or 
educational institution or branch of the armed forces. 

The data record 141 also includes a corresponding set 142 of query 
results. The set 142 includes, with respect to each component, the result of a 
verification query to the pertinent third party. If, therefore, the component 

10 relates to the candidate's undergraduate degree, the verification query will be 
to the candidate's college, and the result will be a determination that the 
college did in fact (or did not) grant a degree to the candidate, and optionally 
in addition that the degree is indeed in the specified field, was indeed granted 
on the specified date, etc.. These latter options illustrate that each query may 

15 optionally include one or more sub-queries. 

The verifiable component set 141 may include the text of a reference 
that the candidate has ascribed to a recommending third party. In this case, 
there is generated a verification query to the recommending third party, and 
the query, in one embodiment, presents to the recoirunending third party the 

20 text of the reference. The query result set 142 therefore includes the 

determination that the recommending third party is indeed (or is not) the 
source of the reference. The query result set 142 also optionally includes the 
date that the recommending third party provided the reference. 

In box 12 the identifier 143 is communicated to the candidate. In box 

25 13, access to the data record 14 is permitted when the identifier 143 is 

provided. In this manner, verifiable components of the personal background 
data appear in the data record with authenticated results, and the data record 
is accessible to those who have been given the identifier by the candidate. The 
candidate is therefore able to provide selective access to the data record. 

30 Thus, the candidate himself can provide access to his pre-authenticated 

background data, so that employers or others who are given access can trust 
the information they are given. Unlike conventional background-checking 
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services, embodiments according to the invention do not require employers to 
conduct background checks on candidates. Rather, candidates themselves 
can provide employers with access to pre-authenticated background data. 

Fig. 2 is a block diagram illustrating generally a process flow associated 
5 with a further embodiment in accordance with the present invention. In this 
method, long-term storage 28 commvmicates with six processes, as indicated 
by the arrows; each of these processes is described in further detail below: 
registrant data-entry process 21, verification process 22, registrant-request 
process 23, process 24 for outside requests on a registrant, process 25 for 

10 outside requests on a non-registrant, and process 26 for finding a registrant. 

As will be described in further detail below, a registrant enters data in 
process 21, and the data is communicated to long-term storage 28 for 
verification and storage. One typical registrant is a job candidate, but may 
also be, for example, a candidate for admission to a school or other institution, 

15 as will be appreciated by those of skill in the art. Another typical registrant is 
a person who is currently in a job, but would like to be able to be found easily 
based on verifiable data, should the person change jobs or locations in the 
future. Once the registrant has entered data through process 21, the data is 
used for verification process 22. The registrant may then request distribution 

20 of verification results, as in registrant-request process 23. Also, an outside 
user may then request verification results, using process 24 for outside 
requests on a registrant. The outside user is typically an employer, but may 
also be a school or other institution that requires verification of personal 
background data. If an outside user requests verification of data on a person 

25 who is not a registrant, the method uses process 25, for outside requests on 
non-registrants, to undertake a verification process, including verification 
process 22, and to communicate data to long-term storage 28. In process 26, 
an outside user searches for a registrant using key data. Here, the outside 
user need not be an employer, but may be anyone who wishes to contact a 

30 person based on verified personal background data. 

Fig. 3 shows an embodiment of a system in accordance with the 
present invention. Remote computer 31 is connected via a network 32, such 
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as the Internet, to a host computer 34, which may be a World Wide Web 
server. In the latter case, the host computer 34 provides HTML pages (or 
pages in other languages, as known to those of skill in the art), for access by 
remote computer 31 by means of which may be entered data, as described 
5 below. Processes rimning on remote computer 31 and host computer 34 
enable a job candidate or other registrant to enter personal data, including a 
set of data components for verification. The processes then communicate this 
data over network 32 to host computer 34, and store the data in a digital 
storage medium such as content storage 33, which may be realized as a hard 
10 disk drive. 

Host computer 34 is cormected to a plurality of computers of third 
parties via network 32, including, but not limited to, computers of employers 
(third party 35), educational institutions (third party 36), and military or other 
goverrunent institutior\s (third party 37). Host computer 34 rims a process 

15 which communicates verification queries, based on the stored registrant's 
data, over network 32 to computers of the third parties, including third 
parties 35, 36, and 37. Separate data components may be commxmicated to 
different parties over network 32. Thus, for example, a verifiable component 
that includes the data that a registrant attended a given university may be 

20 communicated to third party 36, while a verifiable component that includes 
the data that a registrant attained a given military rank may be communicated 
to third party 37. These parties' computers then run processes which 
communicate back query results to host computer 34, via network 32, A 
process rurming on host computer 34 stores the query results in a data record 

25 on digital storage medium 33, associating query results separately with each 
corresponding verifiable component. 

An outside user's remote computer 38 is connected over network 32 to 
host computer 34. Processes rurming on computer 38 and host computer 34 
enable the outside user to enter a verification request, including a set of 

30 components of personal background data for verification; this data is then 

communicated over network 32 to host computer 34, which stores the request 
in a digital storage medium such as content storage 33. Processes rurming on 
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computer 34 determine whether the request is on a registrant or non- 
registrant. If it is on a registrant, the process retrieves the registrant's data 
record from digital storage medium 33, and communicates its data to the 
outside user's remote computer 38. If the request in on a non-registrant, the 
5 process performs the verification procedures described above for a 
registrant's request, and communicates the results to the outside user's 
remote computer 38. 

Further information concerning the Internet and E-mail (both of which 
terms are used throughout this specification) is provided, for example, in 

10 Gralla, How the Internet Works (Ziff-Davis Press, 1996), which is hereby 
incorporated by reference; see especially pages 44-49. 

Fig's 4A through 9B illustrate the logical flow of methods according to 
embodiments of the invention. As will be appreciated by one of skill in the 
art, these logical flows also illustrate the components of processes running on 

15 computers in systems according to embodiments of the invention. For 

example, they may illustrate the processes described above for the system of 
Fig. 3, in a fashion knoWn to those of skill in the art. 

Fig's 4A and 4B show the process flow for the registrant data-entry 
process, summarized as process 21 in Fig. 2. At box 401 of Fig. 4A, the user of 

20 a website is shown a welcome screen (HTML page) that introduces the user to 
the site, and to the process for data-entry that will be described below. At box 
402, the registrant user is shown a description of the service options that the 
user may elect, including the benefits and prices of each. The user selects an 
initial service option at box 403, and is shown an overview of the guided 

25 registration process in box 404. At box 405, the registrant user enters his or 
her basic contact information, and at box 406 enters payment information, 
such as a credit card number. At box 407, upon receiving the registrant's 
information, the host computer assigns a unique alpha-numeric identifier to 
the file, for internal use only. At box 408, the registrant enters, via a template, 

30 the personal background data that he or she wishes to verify; each 

background data component to be verified may be entered using a different 
template. 
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The registrant data-entry process continues in Fig, 4B. The user is next 
shown, in box 409, a template containing the data that he or she completed, to 
review and modify as necessary. An "okay" button near the template allows 
the registrant to skip to box 411 (below); otherwise, box 409 forms a loop with 
5 box 410, in which the registrant is provided with an opportunity to make 
changes or corrections to the template data. The registrant is next provided 
with a yes /no decision on whether to submit the template data (box 411), and 
(if yes) payment is authorized (in box 412) based on the data that the user 
provided in box 406. The unique identifier temporarily assigned to the 

10 registrant in box 407 is now assigned to the registrant (box 413). In some 
embodiments, the registrant may now set a password, which gives access to 
his data record (box 414). In box 415, the registrant is shown a "thank you" 
message, and a summary explanation of the resume verification process. At 
this point, the registrant's data file is sent to temporary storage, for later 

15 submission to the verification process described below. 

Fig's 5A and 5B explain in detail the verification process, which is 
summarized as process 22 in the block diagram of Fig. 2. Once the registrant 
has entered data, as described above, the verification process occurs. As 
shown in box 501 of Fig. 5A, the registrant's data file, created in box 409 

20 above, is first retrieved from storage, in the format of a Master Verification 
Document (MVD). The MVD has spaces for outcomes of query requests of 
the verification process, for each pertinent background data component; and a 
tracking number for the MVD. A tracking number is assigned to the MVD in 
box 502. The system reviews submitted data for completeness and errors, in 

25 box 503. If there are none, the process continues with box 506, below. If there 
are incomplete or flawed elements in the data record, as determined by pre- 
established standards programmed into the host computer, the system sends 
a query about the elements to the registrant (by e-mail, for example), along 
with a time limit for response (box 504). If the time limit is exceeded for the 

30 registrant's response, the system proceeds with box 506. In box 506, the MVD 
data is divided by third party entities to be contacted, and sorted into those 
with whom verification can be attempted (for use in box 508) and cannot be 
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(for use in box 507). For those entities with whom verification cannot be 
attempted, a proper code is entered on the MVD in a data component set 
aside for such purpose (box 507). 

Fig. 5B continues the verification process. As described in box 508, an 
5 electronic query is sent to third party entities with whom verification can be 
attempted. The query is associated with a preceded time Hmit for the third 
party entity to respond. If the third party responds within the time Hmit, the 
process continues with box 509; otherwise with box 510. In box 509, the 
information received from the third party entity is coded and entered on the 

10 MVD. The responses, entered on the MVD, may be "verified as reported," 

"verified in part" (with the portion verified noted), "corrected" (with the third 
party's correction noted), "authenticity denied," or "no response received on 
this item." Alternatively, the responses may be "confirmed," "claim is 
inaccurate," "unwilling to confirm or deny," or "unable to confirm or deny." 

15 In box 510, if no response is received within the time limit, a second query for 
verification is sent to the third party. If the second query is answered, the 
process goes to box 509. If not, the code "no response to query" is entered on 
the MVD. With the query process finished, a completed MVD may be sent to 
a recipient, as will be described below in connection with registrant-request 

20 process 23, process 24 for outside requests on a registrant, process 25 for 

outside requests on a non-registrant, and process 26 for finding a registrant 
(box 511). The completed MVD is stored in a data storage medium (box 512). 

Note that, while Figs. 5A and 5B have illustrated an electronic query 
process, some verification may be done by other means, particularly when 

25 third parties do not provide the necessary electronic connections. Thus, some 
verification may be performed by telephone, mail, or facsimile, or other 
conventional communication techniques. 

Figs. 6A and 6B show in detail the registrant-request process 23, 
summarized in the block diagram of Fig. 2. In Fig. 6A, the registrant first 

30 completes a request for distribution, noting what portions of his or her MVD 
are to be distributed, and to whom (box 601). The MVD may be distributed to 
various third parties, including the types of third parties shown in Fig. 3. In 
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one embodiment, the system allows the registrant to purchase, over the 
Internet or other network, electronic "chits," each of which allow the 
registrant to send a given number of verified resumes to third parties. In a 
further embodiment, the system generates a list of e-mail addresses for 
5 commonly-requested institutions, in order to aid the registrant in selecting 
third parties. Once the request for distribution is complete, the system 
verifies the registrant's identity by requiring the registrant to enter his imique 
identifier (from box 413 of Fig. 4B), and password (from box 414 of Fig. 4B). 
The registrant is presented with service options and prices (box 603); then the 

10 registrant selects a service option (including a choice of formats for 

distribution), specifies recipients, and provides transmission information (box 
604). Once the registrant has entered payment information and authorized 
payment (boxes 605 and 606), the registrant's MVD is retrieved from storage 
(box 607), and, in some embodiments, the registrant is given the opportunity 

15 to review the MVD before dissemination (box 608). In other embodiments, 
the process continues with box 611 of Fig. 6B. 

If the registrant is given the opportunity to review the MVD, then he or 
she is given the opportunity to have the MVD updated to reflect new or 
future information (box 609 of Fig. 6B). If the update option is selected (as in 

20 box 610 of Fig. 6B), the system, in one embodiment, repeats processes 506 
through 510 and then the process continues with box 611 of Fig. 6B; in this 
case, information that has already been authenticated will remain present in 
the database, and new information will be added. Alternatively, the system 
may also give the registrant the opportimity to have the MVD updated at 

25 given intervals of time (e.g. every six months) or to have the MVD updated at 
registrant-determined intervals of time. In either case, the process continues 
with box 611 of Fig. 6B. In box 611, the MVD is disseminated as specified by 
the registrant in box 604. A confirmation of MVD dissemination is e-mailed 
to the registrant in box 612. 

30 When the MVD is distributed, it may be distributed in the form of a 

certified, tamper-proof or tamper-revealing document, containing the data 
record. For example, the MVD may be distributed as a watermarked original 
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document containing the data record. Alternatively, the MVD may be 
distributed as a notarized paper with a seal, or as an e-mail message or 
electronic file containing an electronic watermark or electronic certification. 
Electroruc certification systems are available, for example, from RSA Security, 
5 Bedford, Massachusetts, www.rsasecurity.com, including those using public- 
private key systems; the contents of this website are hereby incorporated 
herein by reference. In each case, the document is provided with a 
certification - that is, marked or identified in a way that is indicative of 
authentication of the document, and in a way that is appropriate for the 

10 medium of the document (whether paper, electronic, or otherwise). 

Figs. 7 A through 7C show the details of process 24 for outside requests 
on a registrant, sunmiarized in the block diagram of Fig. 2. First, in box 701 of 
Fig. 7A, an outside requestor who wishes to receive verified backgrotind data 
information on a registrant completes a Notice of Request for Verification 

15 Materials on a Registrant, including the registrant's unique identifier. Next, 
the system verifies the registrant's identity via the registrant's unique 
identifier (from box 413 of Fig. 4B); if the identifier is not valid, the requestor 
is sent to process 25, described below (box 702). If the registrant's imique 
identifier is valid, the requestor is asked in box 703 to choose between 

20 accessing the registrant's MVD (which requires the MVD tracking number 
from box 502), or entering specific data to be checked (in which case the 
process continues with box 705). The system checks the validity of the MVD 
by its tracking number and checks the integrity of the file (box 704). In box 
705, the system checks whether pertinent legal regulations require that the 

25 registrant be notified of the request, and notifies the registrant if it is required. 
Next, the requestor is notified that the MVD is available (box 706). Service 
options and prices are presented, based on the outcomes of boxes 703 through 
706 (box 707), and the requestor selects a service option (including the data 
format for dissemination), and provides transmission information (box 708). 

30 Continuing as in Fig. 7B, the requestor enters payment information 

(box 709) and authorizes payment (box 710). If the whole MVD is chosen to 
be distributed, dissemination to the requestor is completed, and the process 
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goes to box 719, below (box 711). If a portion of the MVD is chosen to be 
distributed, the requestor indicates the selected portion, and then 
dissemination to the requestor is completed, and the process goes to box 719. 
If any MVD data is unavailable, or is not chosen, the requestor first enters the 
5 data to be verified (box 713) in a fashion similar to boxes 407 through 411, 
above. A new record is created imder the registrant's uiuque identifier 
(obtained from box 413, above), a tracking number is assigned for this record 
(in a similar fashion to box 502, above), and the requestor is notified that 
requested data are in the verification process. The verification process 
10 proceeds in a similar fashion to process 22 (described in detail above), and 
dissemination to the requestor is completed. The process continues with box 
714. 

In box 714 of Fig. 7C, the requestor is given a choice for a record to be 
maintained. If he or she chooses not to maintain a record, the temporary 
15 record is inactivated, and the process proceeds to box 719. However, if he or 
she does choose to maintain a record, the service and price options are 
presented (box 715). 

Continuing with box 716 of Fig. 7C, the requestor makes the choice 
described in box 714, is presented with a payment option (box 717) and 
20 authorizes payment (box 718). The verification record is filed with the 
registrant's master file in a digital storage medium (box 719). In one 
embodiment, the registrant is notified that an Outside Verification Request 
has been filed (box 720). 

Figs. 8A and SB show the process for an outside request on a non- 
25 registrant, summarized as process 25 in the block diagram of Fig. 2. First, a 
requestor completes a Notice of Request for Verification Materials on a non- 
registrant or without access to the registrant's unique identifier (box 801). At 
this point, depending on the privacy laws of relevant jurisdictions, the system 
may not allow the requestor to have any access to information about the non- 
30 registrant. Where these conditions do not pertain, the requestor is presented 
with service options and prices (box 802), selects a service option (including 
format for dissemination), and provides transmission information (box 803). 
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The requestor enters payment information (box 504) and authorizes payment 
(box 805). Next, the requestor enters the data to be verified, in a process 
similar to that of boxes 407 to 411 of Fig's 4A and 4B (box 806) and a 
temporary unique identifier is assigned to the person whose background data 
5 will be verified (box 807). The system next checks whether legal regulations 
require that the subject of the authentication be notified of the request, and 
notifies the subject if required. The verification process then proceeds, in a 
similar fashion to process 22 (box 809 of FIG. 8B). 

Continuing with Fig. 8B, the requestor next receives the results of the 

10 verification process (box 810). In one embodiment, the requestor is given the 
choice for a record to be maintained (box 811). If the choice is not to maintain 
a record, the temporary record is inactivated and the process continues with 
box 719. If a record will be maintained, the requestor is presented with . 
service options and prices (box 812), and indicates his choice (box 813). The 

15 requestor is also presented with payment options (box 814) and payment is 
authorized (box 815). The verification record is filed under the subject 
person's unique identifier (box 816) and the person's imique identifier is 
given to the requestor (box 817). 

In yet another embodiment of the present invention, there is an 

20 arrangement provided for searching a database of pre-authenticated 

background data. This embodiment facilitates interpersonal networking by 
enabling one to search through a database of personal background data that is 
authenticated, and enabling individuals to initiate registration with such a 
database. In this embodiment, the procedures described above for producing 

25 authenticated background data may typically be followed by numerous 

registrants. The result is a database of authenticated backgrotind data. Once 
such a database is created, members of the public, including employers, may 
cause a search of the database to be initiated. The searchers need not have the 
registrant's unique identifier. The search may use key words and topics of 

30 interest. The searchable database thus facilitates networking, by providing 
employers and others with the ability to initiate a search of a database of 
personal background data that is known to be authenticated, and by 
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providing candidates with a forum where their background data can be 
found, and will not be discounted as potentially-dishonest. 

Alternatively, the searchable database may be implemented as a 
database that is directly accessible over the Internet, including as a World 
5 Wide Web server accessible through an HTML-implemented, web-page 
search engine. 

Key word search methods may be used with the searchable databases. 
See, for example, the methods described in United States patents 5,799,304 
(Miller, "Information Evaluation''); 5,649,186 (Ferguson, "System and method 

10 for a computer-based dynamic information clipping service"); 5,537,586 

(Amram et al., "Enhanced apparatus and methods for retrieving and selecting 
profiled textural information records from a database of defined category 
structures"); 5,418,951 (Damashek, "Method of retrieving documents that 
concern the same topic"); and 5,384,703 ("Withgott et al., "Method and 

15 apparatus for summarizing documents according to theme"), which are 

hereby incorporated herein by reference. Such search methods may be used 
to deternaine classes of data records to view as search results. 

Embodiments of the invention provide particular advantages for 
networking because they allow for searching of data records where only 

20 fragmentary information is known about a person. For example, suppose a 
famous pastry chef registered with a database in a fashion sinrdlar to those 
described above. His authenticated personal background data would then 
appear in a data record accessible to those who have been given its identifier. 
Additionally, however, embodiments of the invention allow persons who 

25 wish to find the pastry chef to search through a database of authenticated 
personal background data. The searchers need not be employers, but could 
be interested in contacting the pastry chef for other reasons. They might have 
only fragmentary information about the chef. For example, while the data 
record contained the pastry chefs full name, education, employment 

30 background, and history of awards, the searchers might only know that the 
chef worked at a given restaurant two years ago. Using key word search 
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tec±iniques, each verifiable component of the data records in the database 
could be searched to find matches for the searchers' request. 

Once it filters the data, the system provides searchers with a way of 
contacting the person whose record has been found. This contact method is 
5 provided by the registrant when he registers, in a fashion similar to that 
described above, and may include an e-mail address. Alternatively, the 
system may inform the registrant that the named requestor is looking for 
someone, who may be the registrant, based on the set of data that the 
requestor has specified; thus leaving it to the registrant to contact the 

10 requestor if desired. 

In an increasingly mobile world, the searchable database thus 
facilitates finding former colleagues, or members of other orgaruzations, with 
skills or interests or characteristics that are being sought but on whom key 
data are now missing. 

15 Note also that data records according to embodiments of the invention 

need not contain a complete record of a person's background data. Thus, for 
example, the pastry chef's data record inight include only verifiable 
components related to his work at one restaurant, and not contain his 
educational background. In such a case, a search of the personal backgroimd 

20 database would only attempt to find a record based on the components that 
were present. 

A searchable database embodiment is now described with reference to 
Figs. 9 A and 9B. The process flow shown in these figures is a detailed version 
of process 26 of Fig. 2, for finding a registrant. 

25 First, at step 901, a requestor who wishes to find a party based on 

authenticated background data completes a Notice of Request for 
Identification of a Party, which may be implemented as a template-based 
form on an internet website. This Notice simply informs the system that the 
requestor wishes to find a party, as opposed to using any of the other features 

30 of the system that are described above. 

As described at step 902, the requestor next fills out an initial template 
to indicate the kinds of data that the requestor has on the party. The system 
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lists all of the kinds of data that it stores on registrants, next to a yes /no query 
on whether the user has that kind of information. If, for example, the 
requestor knows that the party worked at an office of a given corporation, in a 
given city, in a given position, during a given timeframe, the requestor would 
5 fill out the "yes" box next to the corporation, location, job position, and dates 
of employment fields. 

At step 903, the system deternunes whether any of the listed fields has 
a "yes" box checked next to it. If none do, then the system informs the 
requestor that the system is imable to perform a search based on the kinds of 

10 information that the requestor has on the subject of the request, and the 
process is terminated. 

If, however, it is determined that the requestor's information fits at 
least one of the fields of data in the database, the requestor is told that the 
process will continue, and the process continues with step 904. In step 904, 

15 the system presents the requestor with service options and prices. The 
options may include, for example, the textual format in which the search 
results will be disseminated, the means by which they will be distributed (e.g. 
by e-mail, fax, mail, etc.), and the number of reports which will be sent. The 
prices may vary based on the expense of the service options. The requestor 

20 selects a service option, and provides information necessary to transmit the 
search results (e.g. e-mail addresses, mail addresses, etc.) (step 905). The 
requestor enters payment information and authorizes payment (steps 906 and 
907). 

At step 908, the requestor is next presented with a Finder Template, 
25 which may be a web-page with a series of template fields for completion by 
the requestor. These fields are structured to elicit information from any of the 
fields of information in the database. For example, if the database has 
information on corporations that employed registrants, and dates that they 
did so, then there will be template fields corresponding to each of these types 
30 of information. Once the requestor has filled out the Finder Template, the 

system assigns a temporary identifier to the search (step 909) and searches for 
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registrants based on the profile provided in the requestor's Finder Template 
(step 910). 

Once the system has foiind data records of registrants, it checks the 
data records to see whether each registrant wishes to be notified of any search 
5 requests which identify his data record, and whether each registrant has 
asked to authorize distribution of any search results (step 911). Such 
notification preferences are given by registrants when they register, in a 
manner similar to that described in the registration process above. If a 
registrant has chosen to be notified, the system notifies the registrant. If a 

10 registrant wishes to authorize distribution of results, the system sends a 

request for authorization to the registrant. Additionally, where pertinent laws 
require authorization in order to release backgroimd data, the system 
automatically sends a request for authorization to the registrant. 

Next, if the system has foimd a record but a release is not granted, the 

15 requestor is notified that the subject party has not authorized release of the 
record, and the process is terminated (step 912). If the system has found a . 
record, and necessary authorization has been given, or if no authorization was 
required at all, the process continues with step 913. 

Finally, in step 913, the system distributes records to the requestor, in 

20 accordance with the service option which the requestor selected. In this way, 
the process flow of Fig's 9A and 9B allows people to search for information in 
a database of pre-authenticated personal backgroimd data. 

It should be noted that the systems and methods described above 
should not be confused with systems and methods for verifying that a given 

25 holder of a set of data on a person is indeed that person. The latter systems 
and methods include, for example, fingerprinting. Rather, the systems and 
methods described above relate to authenticating personal background data, 
whether held by a job candidate or any other person, and also to structuring a 
database to provide access to authenticated personal background data. 

30 Although this description has set forth the invention with reference to 

several preferred embodiments, those of ordinary skill in the art will 
understand that one may make various modifications without departing from 
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